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3GPP SIP URI Inter-Operator Traffic Leg Parameter 
Abstract 


In 3GPP networks, the signaling path between a calling user and a 
called user can be partitioned into segments, referred to as traffic 
legs. Each traffic leg may span networks belonging to different 
operators and will have its own characteristics that can be different 
from other traffic legs in the same call. A traffic leg might be 
associated with multiple SIP dialogs, e.g., in case a Back-to-Back 
User Agent (B2BUA) that modifies the SIP dialog identifier is located 
within the traffic leg. 


This document defines a new SIP URI parameter, 'iotl' (an 
abbreviation for Inter-Operator Traffic Leg). The parameter can be 
used in a SIP URI to indicate that the entity associated with the 
address, or an entity responsible for the host part of the address, 
represents the end of a specific traffic leg (or multiple traffic 
legs). 


The SIP URI 'iotl' parameter defined in this document has known uses 
in 3GPP networks. Usage in other networks is also possible. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7549. 
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Les 


Introduction 


In a 3GPP network, an end-user device can be attached (e.g., using a 
radio access network) to its own operator network (home network) 
[TS.3GPP.24.229] or to another operator’s network (visited network) 
[TS.3GPP.24.229]. In the latter case, the user is referred to as a 
roaming user. 


3GPP operator networks are often not connected directly to each 
other. Instead, there might be intermediate networks, referred to as 
3GPP transit networks, between them. Such transit networks act on 
the SIP level or the IP level. 


In 3GPP networks, the signaling path between a calling user and a 
called user can be partitioned into segments, referred to as traffic 
legs. Each traffic leg may span networks belonging to different 
operators and will have its own characteristics that can be different 
from other traffic legs in the same call. A traffic leg might be 
associated with multiple SIP dialogs, e.g., in case a B2BUA [RFC3261] 
that modifies the SIP dialog identifier is located within the traffic 
leg. 


The traffic leg information can be used by intermediary entities to 
make policy decisions related to, e.g., media anchoring, signaling 
policy, insertion of media functions (e.g., transcoder), and 
charging. 


The figure below shows two users (Alice and Bob) and the different 
type of networks that the signaling might traverse. The signaling 
path can be divided into multiple traffic legs, and the type of 
traffic legs depends on how the signaling is routed. 
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Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob 
Home + + s + * Home 
+ ++++++++++++++++++ + +4 
+ + +4 
+ + +4 
+ AFHEHALHEFATHEFATHEFATHEFAFT+ + 
+ + + + 
Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob 
Visited Visited 
ORIG HNW = Originating 3GPP Home Network 
TERM HNW = Terminating 3GPP Home Network 
ORIG VNW = Originating 3GPP Visited Network 
TERM VNW = Terminating 3GPP Visited Network 
TRANSIT NW = 3GPP Transit Network 


Figure 1: 3GPP Operator Network Roaming Roles 


In Figure 1, Alice is a user initiating communication with Bob. Also, 


consider the following information: 


Alice is attached to an originating network, which is either the home 


network of Alice or a visited network (in case Alice is roaming). 
both cases, any originating service is provided by the home network 
of Alice. 


Bob is attached to a terminating network, which is either the home 
network of Bob or a visited network (in case Bob is roaming). In 
both cases, any terminating service is provided by the home network 
of Bob. 


A transit network providing transit functions (e.g., translation of 
free phone numbers) may be included between the originating and 
terminating networks and between visited and home networks. 


This document defines a new SIP URI parameter [RFC3261], 'iotl' (an 
abbreviation for Inter-Operator Traffic Leg). The parameter can be 
used in a SIP URI to indicate that the entity associated with the 
address, or an entity responsible for the host part of the address, 
represents the end of a specific traffic leg (or multiple traffic 
legs). 
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4. 


4 


This document defines the following 'iotl' parameter values: 
o homea-homeb 

o homeb-visitedb 

o visiteda-homea 

o homea-visiteda 

o visiteda-homeb 


SIP entities that do not support the SIP URI 'iotl' parameter will 
simply ignore it, if received, as defined in [RFC3261]. 


Conventions 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Applicability 


The SIP URI ’iotl’ parameter defined in this document has known uses 
in 3GPP networks. Usage in other networks is also possible. 


Traffic Leg Examples 
1. General 


This section describes examples of different types of traffic legs in 
3GPP networks. 


-2. Originating Roaming Call 


In this case, Alice is located in a visited network. When Alice 
sends the initial SIP INVITE request for a call, one traffic leg 
(referred to as the 'visiteda-homea' traffic leg) represents the 
signaling path between the User Agent (UA) of Alice and the home 
Serving Call Session Control Function (S-CSCF) [TS.3GPP.24.229] of 
Alice. 
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4. 


4. 


5. 


Bi 


4. 


is 


Terminating Roaming Call 


In this case, Bob is located in a visited network. When the home 
S-CSCF of Bob forwards the initial SIP INVITE request for a call 
towards Bob, one traffic leg (referred to as the 'homeb-visitedb' 
traffic leg) represents the signaling path between the home S-CSCF of 
Bob and the UA of Bob. 


Call from Originating Home to Terminating Home 


In this case, the home S-CSCF of Alice forwards the initial SIP 
INVITE request towards the home S-CSCF of Bob. The signaling path 
between the S-CSCFs represents one traffic leg (referred to as the 
'homea-homeb' traffic leg). 


'iotl' SIP URI Parameter 
Usage 


As specified in [RFC3261], when a SIP entity inserts a SIP URI in an 
initial request for a dialog, or in a stand-alone request, the SIP 
URI will be used to route the request to another SIP entity, 
addressed by the SIP URI, or to a SIP entity responsible for the host 
part of the SIP URI (e.g., a SIP registrar). If such an entity 
represents the end of one or more traffic legs, the SIP entity 
inserting the SIP URI can add a SIP URI 'iotl' parameter to the SIP 
URI to indicate the type(s) of traffic leg. Each parameter value 
indicates a type of traffic leg. 


For routing of an initial SIP request for a dialog, or a stand-alone 
SIP request, a SIP entity can add the 'iotl' parameter to (a) the SIP 
URI of the Request-URI [RFC3261] or (b) the SIP URI of a Route header 
field [RFC3261] of the SIP request. SIP entities can add the ’iotl’ 
parameter to the SIP URI of a Path header field [RFC3327] or a 
Service-Route header field [RFC3608] in order for the parameter to 
later occur in a Route header field. 


When a SIP entity receives an initial request for a dialog or a 
stand-alone request, which contains one or more SIP URI ’iotl’ 
parameters, it identifies the type of traffic leg in the following 
way: 


o if the SIP request contains a single Route header field containing 
a SIP URI with an 'iotl' parameter, that parameter identifies the 
type of traffic leg; 
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o if the SIP request contains multiple Route header fields 
containing a SIP URI with an 'iotl' parameter, the 'iotl' 
parameter associated with the SIP URI of the topmost Route header 
field (or, if the SIP URI of the topmost Route header field does 
not contain an 'iotl' parameter, the SIP URI of the Route header 
field closest to the topmost) identifies the type of traffic leg; 
or 


o if a SIP request contains an 'iotl' parameter only in the Request- 
URI SIP URI, the 'iotl' parameter identifies the type of traffic 
leg. 


During SIP registration [RFC3261], entities can add the ’iotl’ 
parameter to the SIP URI of a Path or Service-Route header field if 
the entity is aware that the SIP URI will be used to indicate the end 
of a specific traffic leg for initial requests for dialogs or stand- 
alone requests sent on the registration path. 


As defined in [RFC3261], a SIP proxy must not modify or remove URI 
parameters from SIP URIs associated with other entities. This also 
applies to the 'iotl' parameter. 


5.2. Parameter Values 
5.2.1. General 


This section describes the SIP URI 'iotl' parameter values defined in 
this specification. 


Note that, when a request is routed between different networks, the 
request might traverse one or more IBCFs (Interconnection Border 
Control Functions) acting as network border entities. 


5.2.2.  homea-homeb 


This value indicates that a SIP entity responsible for the host part 
of the SIP URI associated with the parameter represents the end of a 
traffic leg between the home network (originating) of the calling 
user and the home network (terminating) of the called user. 


In 3GPP, this traffic leg is between two S-CSCFs. 

5.2.3. homeb-visitedb 
This value indicates that the SIP entity addressed by the SIP URI 
associated with the parameter represents the end of a traffic leg 


between the home network (terminating) of the called user and the 
visited network (terminating) in which the called user is located. 
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In 3GPP, this traffic leg is between the home S-CSCF and the User 
Equipment (UE) of the called user or between the Service 
Centralization and Continuity Application Server (SCC AS) in the home 
network of the called user and Access Transfer Control Function 
(ATCF) in the visited network of the called user. 


5.2.4.  visiteda-homea 


This value indicates that a SIP entity responsible for the host part 
of the SIP URI associated with the parameter represents the end of a 
traffic leg between the visited network (originating) in which the 
calling user is located and the home network (originating) of the 
calling user. 


In 3GPP, this traffic leg is between the UE and the home S-CSCF of 
the calling user or between the Proxy Call Session Control Function 
(P-CSCF) in the visited network, serving the calling user and the 
home S-CSCF of the calling user. 


5.2.5.  homea-visiteda 


This value indicates that the SIP entity addressed by the SIP URI 
associated with the parameter represents the end of a traffic leg 
between the home network (originating) and the visited network 
(originating) in which the calling user is located. 


In 3GPP, this traffic leg is between the home S-CSCF of the calling 
user and the Transit and Roaming Function (TRF) [TS.3GPP.24.229] 
serving the calling user and exists in scenarios where the home 
S-CSCF of the calling user forwards a request back to the visited 
network where the UE of the calling user is located. An example of 
this is when the Roaming Architecture for Voice over IMS with Local 
Breakout (RAVEL) [TS.3GPP.24.229] feature is enabled. 


5.2.6.  visiteda-homeb 


This value indicates that a SIP entity responsible for the host part 
of the SIP URI associated with the parameter represents the end of a 
traffic leg between the visited network (originating) of the calling 
user and the home network (terminating) of the called user. 


In 3GPP, this traffic leg is between the TRF [TS.3GPP.24.229] serving 
the calling user and the home S-CSCF of the called user and exists in 
Scenarios where a request is forwarded from the visited network where 
the calling user is located directly to the home S-CSCF of the called 
user. An example of this is when the RAVEL [TS.3GPP.24.229] feature 

is enabled. 
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6. Syntax 
6.1. General 


This section defines the ABNF for the 'iotl' SIP URI parameter. The 
ABNF defined in this specification is conformant to RFC 5234 
[RFC5234]. 


This specification does not create an IANA registry for 'iotl' 
parameter values. A registry should be considered if new parameter 
values are defined in the future. 


6.2. ABNF 
The ABNF [RFC5234] grammar for this SIP URI parameter is: 


uri-parameter -/ iotl-param 


iotl-param = iotl-tag "=" iotl-value ["." iotl-value] 

iotl-tag SINIO” 

iotl-value = "homea-homeb" / "homeb-visitedb" / "visiteda-homea" 
/ "homea-visiteda" / "visiteda-homeb" / other-iotl 

other-iotl = l*iotl-char 

iotl-char = alphanum / "-" 


;; alphanum defined in RFC 3261 
7. Security Considerations 


The information in the 'iotl' parameter is used for making policy 
decisions. Such policies can be related to charging and triggering 
of services. In order to prevent abuse, which could cause user 
billing or service failure, the parameter SHOULD only be used for 
making policy decisions based on the role by nodes within the same 
trust domain [RFC3325], and network boundary entities MUST NOT 
forward information received from untrusted entities. In addition, 
an agreement MUST exist between the operators for usage of the 
roaming role information. 


General security considerations for SIP are defined in [RFC3261] 
8. IANA Considerations 


Per this specification, IANA has added one new value to the "SIP/SIPS 
URI Parameters" registry as defined in [RFC3969]. 


Parameter Name  Predefined Values Reference 


iotl Yes RFC 7549 
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Appendix A.  3GPP Examples 
A.1. General 


This section contains example call flows based on 3GPP usage of the 
SIP URI 'iotl' parameter. 


A.2. The UE Registers via P-CSCF 


The Visited Proxy (P-CSCF) adds the 'iotl' value 'homeb-visitedb' to 
the Path header field of the REGISTER request to be used for 
terminating routing towards Alice. The Home Proxy (S-CSCF) adds the 
'iotl' value 'visiteda-homea' to the Service-Route header field to be 
used for originating initial/stand-alone requests from Alice. 


Visited Proxy Visited Proxy Home Proxy Home Proxy 
Alice's . . . . POGSOE . . . . . IBCF-V S aseo . . IBCF-H x . . . S-CSCF 
| | | | | 
| | REGISTER F1 | | | | 
--------------- >| REGISTER F2 | | 
| --------------- >| REGISTER F3 | | 


F1 REGISTER Alice -> P-CSCF 
REGISTER sip:registrar.homel.net SIP/2.0 


F2 REGISTER P-CSCF -> IBCF-V 
REGISTER sip:registrar.homel.net SIP/2.0 
Path: <p-cscf URI;iotl=homeb-visitedb> 


F3 REGISTER IBCF-V -> IBCF-H 
REGISTER sip:registrar.homel.net SIP/2.0 
Path: <p-cscf URI;iotl=homeb-visitedb> 


F4 REGISTER IBCF-H -> S-CSCF 


REGISTER sip:registrar.homel.net SIP/2.0 
Path: «p-cscf URI;iotl-homeb-visitedb» 
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F5 200 OK S-CSCF -> IBCF-H 

200 OK 

Path: «p-cscf URI;iotl-homeb-visitedb» 
Service-Route: «s-cscf URI;iotl-visiteda-homea» 


F6 200 OK IBCF-H -> IBCF-V 

200 OK 

Path: «p-cscf URI;iotl-homeb-visitedb» 
Service-Route: «s-cscf URI;iotl-visiteda-homea» 


F7 200 OK IBCF-V -» P-CSCF 

200 OK 

Path: <p-cscf URI;iotl-homeb-visitedb» 
Service-Route: «s-cscf URI;iotl-visiteda-homea» 


F8 200 OK P-CSCF -> Alice 

200 OK 

Path: «p-cscf URI;iotl-homeb-visitedb» 
Service-Route: «s-cscf URI;iotl-visiteda-homea» 


Figure 2: The UE Registers via P-CSCF 
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A.3. Originating IMS Call 


In the originating INVITE request from Alice, the 'iotl' value 
'visiteda-homea', received in the Service-Route header field during 
registration, 


Home Proxy 
Visited Proxy 


Alice's 


INVI 


is added to the Route header field representing the 


(S-CSCF) to indicate the traffic leg type between the 


(P-CSCF) and the Home Proxy (S-CSCF). 


Visited Proxy Visited Proxy Home Proxy Home Proxy 
P=CSCF . &« 2 2 XIBOE-V & ow 48 ze —- nd 
| | 
TE Fl | | | | 
--------------- > | INVITE F2 | | 

|--------------- >| INVITE F3 | | 

| |--------------- >| INVITE F4 | 

| | fy oa 

| | | 180 F5 | 

| | 180 F6 | <--------------- | 

| 180 F7 | <--------------- | | 

F8 l -----—-------- | 


F1 INVITE Alice -> P-CSCF 
INVITE sip:Bob@homeb.net SIP/2.0 
<p-cscf URI>,<s-cscf URI; iotl=visiteda-homea> 


Route: 


F2 INVITE P-CSCF -> IBCF-V 
INVITE sip:Bob@homeb.net SIP/2.0 
«ibcf-v URI>,<s-cscf URI;iotl-visiteda-homea» 


Route: 


F3 INVITE IBCF-V -> IBCF-H 
INVITE sip:BobGhomeb.net SIP/2.0 


Route: 


«ibcf- 


h URI>,<s-cscf URI;iotl-visiteda-homea» 


F4 INVITE IBCF-H -> S-CSCF 
INVITE sip:Bob@homeb.net SIP/2.0 
<s-cscf URI; iotl=visiteda—homea> 


Route: 


Figure 3: Originating IP Multimedia Subsystem (IMS) Call 
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A.4.  Terminating IMS Call 


In the terminating INVITE request towards Alice, the 'iotl' value 
'homeb-visitedb' provided to the Home Proxy (S-CSCF) during 
registration is added to the Route header field representing the 
Visited Proxy (P-CSCF) to indicate the traffic leg type between the 
Home Proxy (S-CSCF) and the Visited Proxy (P-CSCF). 


Home Proxy Home Proxy Visited Proxy Visited Proxy 

S=CSCE uc LBOERSHO. uoa ov IBOESVO I X qe E M. eid cm ms 
| | | 
| INVITE F1 | | | | 
|--------------- >| INVITE F2 | | | 
| | --------------- > | INVITE F3 | | 
| | |--------------- >| INVITE F4 | 
| | | DE i 
| | | | 180 F5 | 
| | | 180 F6 |<--------------- | 
| | 180 F7 |«--------------- | | 
| 180 F8 |«--------------- | | | 
EN | | | 


F1 INVITE S-CSCF -> IBCF-H 
INVITE sip:Bob@visitedb.net SIP/2.0 
Route: «ibcf-h URI>,<p-cscf-v URI; iotl=homeb-visitedb 


F2 INVITE IBCF-H -> IBCF-V 

INVITE sip:BobGvisitedb.net SIP/2.0 

Route: «ibcf-v URI>,<p-cscf-v URI;iotl-homeb-visitedb 
F3 INVITE IBCF-V -» P-CSCF 

INVITE sip:BobGvisitedb.net SIP/2.0 

Route: «p-cscf-v URI;iotl-homeb-visitedb 


F4 INVITE P-CSCF -> Bob 
INVITE sip:Bob@visitedb.net SIP/2.0 


Figure 4: Terminating IMS Call 
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A.5. Call between Originating Home and Terminating Home Network 


The S-CSCF of the originating home network adds the 'iotl' value 
'homea-homeb' in the Request-URI of the INVITE, sent towards the 
S-CSCF of the terminating network to indicate the traffic leg type 
between the S-CSCFs. 


Home-A Proxy Home-A Proxy Home-B Proxy Home-B Proxy Home-B Proxy 
S-CSCF-A . . . . IBCF-A . . . . .IBCF-B . . . . .I-CSCF-B . . .S-CSCF-B 
| | | | | 
| INVITE F1 | | | | 
|--------------- >| INVITE F2 | | | 
| | --------------- > | INVITE F3 | | 
| | |--------------- >| INVITE F4 | 
| | | [RE ee >| 

180 F5 
| | | 180 F6 |<--------------- | 
| | 180 F7 | <--------------- | | 
| 180 F8 |<--------------- | | 
|<--------------- | | 
| | | 


F1 INVITE S-CSCF-A -> IBCF-A 
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0 


F2 INVITE IBCF-a -> IBCF-B 
INVITE sip:Bob@visitedb.net; iotl=homea-homeb SIP/2.0 


F3 INVITE IBCF-B -> I-CSCF-B 
INVITE sip:Bob@visitedb.net; iotl=homea-homeb SIP/2.0 


F4 INVITE I-CSCF-B -» S-CSCF-B 
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0 


Figure 5: Call between Originating Home and Terminating Home Network 
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